When a program is created in conformity with a specification requested by a customer, it is required to avoid violation of the least privilege. That is, the following three points are required: (1) The program does not have privilege without which the program runs; (2) the program does not request a privilege without which the program runs; (3) the program does not set into an object any permission without which the program runs. When a program which would violate the least privilege is created, (a) a program having a needlessly much privilege may be created, and thus a critical damage in which the overall system is captured or the like may occur. Furthermore, (b) when a security problem occurs in the system, a program having a much privilege is suspected and verification of the program of the much privilege may be time consuming and costly. Furthermore, (c) an object having needlessly much permission and/or access may be provided in response to a request, and thus a critical damage such as leakage of information or the like may occur.
The following are specific examples of the least privilege violation. (1) A program is executed by a user/group having a certain level of privilege, and permission/access higher than a minimum level of privilege for the user/group based on the specification of the program is granted to the user/group. [Example 1] An access to a target file can be executed by a general user, however, a program is executed by a manager “Administrator”, and the manager “Administrator” is unnecessarily granted access to the target file according to the manager “Administrator” level of privilege rather than according to just the necessary general user level of privilege. [Example 2] A shutdown API (Application Program Interface” is not called, however, a program is executed by a user/group having a privilege associated with SE_SHUTDOWN_NAME (e.g., a shutdown privilege), and thus the shutdown API should have been called in response to the program executed by the user group having the privilege. (2) Privilege which is equal to or more than the least privilege required for general privilege (user authority) is requested on the specification of the program. [Example 1] API which refers to a file is merely called, however, authority of writing is requested by API OpenFile( ). [Example 2] A file is not backed up, however, SE_BACKUP_NAME (backup privilege) is requested by API AdjustTokenPrivileges( ). (3) An object having unjust permission and/or access is generated. [Example] an object of NULL DACL (access permission is unset, that is, it is equivalent to a setting state of everyone full control).
Since such problems as described above may occur, it is necessary to create a program so as to avoid the least privilege violation. However, there is a case where a developer gives much privilege (authority) to a program without sufficiently understanding the specification of the access control. Furthermore, there is a case where a developer creates an object having unjust permission and/or access.
A conventional technique for addressing the above-mention problems includes a method of detecting a problem by analyzing a source program. However, there are cases where it is difficult and/or impossible to analyze a source program or specifications. Furthermore, it is difficult and/or impossible to detect the least privilege violation corresponding to an execution environment by merely analyzing the source program or the specifications since the source program or specification may depend on an Operating System (OS), security policy, network or the like. Many conventional techniques for access control exist, however, all of these conventional techniques cannot necessarily detect the least privilege violation. Relevant techniques are described in JP-A-2003-186708, JP-A-2007-226495 and JP-A-2008-117026, for example.